Consider an enterprise having multiple systems and potentially multiple geographic locations. Each transaction of the enterprise with an external entity, and many operations within the enterprise on data and/or systems, generates data. The data may indicate changes in inventory, information about sales and customer relations, etc. Data is generally associated with data objects, and frequently, business objects or data objects having a business context. The change to data associated with one or more objects (e.g., business objects or other objects) is referred to herein as an event. Enterprises generally need to keep track of the events, process the generated data (as may be indicated by the event), and make decisions based on the event. Traditionally, enterprises store events in operational databases (operational data stores) among many subsystems within the enterprise, which may include subsystems that are hosted on separate machines, and may be geographically separated. An example of geographic separation of subsystems may be a system local to production plant in one city, and a system local to a distribution plant that could be in a different region, different state, different country, or different continent. There is generally a problem within enterprises, especially as the enterprise grows and as business expands geographically, where the enterprise has “too much” data and “too many” systems. While it is understood that “too much” and “too many” are relative terms, the general problem is that the amount of resources required to handle the data and the systems is higher than the enterprise is capable of providing or is willing to provide. When there is too much data and too many systems, the enterprise loses operational data visibility across the enterprise, and any process for handling events becomes very time consuming and expensive.
For example, consider a business that has more than 100 different enterprise systems located in various locations throughout the world. The data is gathered and stored in an operational database, e.g., an online transaction processing (OLTP) database. If someone within the business wanted to answer a question based on the operational data, or the data generated as events, creating a new operational report may not be a possibility. In research on the subject, it was found that in certain cases, such an operational report cannot be created in less than 6 months. The business traditionally has to search multiple stacks to extract and transform the data before creating an operational report. The searching, extracting, and transforming would need to be repeated for each of the different systems in place, which would require the use of many people and systems. Thus, such an operational report is not even considered a possibility because of the inability to access and transform the data in a cost-effective manner.
In general, it has been found that businesses do not have tools that are specific to operational data. As mentioned above, the operational data only exists as an interim state of data that is then stored in data warehouses and a centralized database to hold the operational data store. Use of the data has then required a great deal of programming around the database to make the data accessible.
Thus, event data within and outside an enterprise has been inaccessible except through a vast amount of enterprise time and cost to analyze and report on the data. The vast amounts of time and cost make the data generally inaccessible to information workers within the enterprise.
Descriptions of certain details and implementations follow, including a description of the figures, which may depict some or all of the embodiments described below, as well as discussing other potential embodiments or implementations of the inventive concepts presented herein. An overview of embodiments of the invention is provided below, followed by a more detailed description with reference to the drawings.